1. Field of the Invention
The present invention relates to a packet relay apparatus connected to a packet network such as the Internet.
2. Description of Related Art
With the widespread use of the Internet in recent years, a variety of communication protocols have been in use. A protocol layer called a transport layer includes TCP (Transmission Control Protocol) and UDP (User Datagram Protocol). TCP achieves reliable data transmission.
FIG. 19 shows a TCP segment structure. TCP segment 102 is included in IP packet (hereinafter simply referred to as “packet”) 101. TCP segment 102 includes TCP header 103 and TCP data 104. TCP data 104 may contain no actual data.
FIG. 28 shows an IP header 500 structure. Protocol number field 501 in IP header 500 contains a number for identifying a protocol in a transport layer included in a packet. For instance, when the protocol in the transport layer included in a packet having IP header 500 is TCP, number 6 is contained in protocol number field 501. When the protocol in the transport layer included in the packet having IP header 500 is UDP, number 17 is contained in protocol number field 501. Source IP address field 502 contains a source IP address. Destination IP address field 503 contains a destination IP address.
Generally, communication over TCP is performed between a pair of a server and a client. The client herein means a network terminal that issues a connection request; the server means a network terminal that receives the connection request. After the client issues the connection request to the server, the server and the client transmit and receive TCP data to and from each other using a packet. In data transmission, the server or client transmits a TCP segment containing TCP data to the associated client or server. When TCP data 104 of TCP segment 102 contains actual data, sequence number field 101 in TCP header 103 indicates the byte number of one-byte data at the top of TCP data 104 in the entire data to be transmitted.
FIG. 20 illustrates basic data transmission over TCP. As shown in FIG. 20, whenever server 201 transmits to client 202, TCP segments X1, X3, and X5, client 202 transmits back to server 201 TCP segments that include a confirmation reply (hereinafter referred to as ACKs) X2, X4, and X6. An ACK number field of each ACK that client 202 transmits contains a value obtained by adding 1 to a sequence number assigned to a TCP segment that client 202 has received. For example, X2, which is a confirmation reply to X1, contains a value derived from adding 1 to a sequence number of X1. Since the ACK number field of X2 shows the value derived from adding 1 to the sequence number of previously transmitted X1, server 201, upon receiving X2, confirms that X1 was properly transmitted to client, and then transmits TCP segment X3. In the operation above, server 201 can confirm that the transmitted TCP data are surely delivered to client 202 when server 201 receives the ACK from client 202.
FIG. 21 illustrates a behavior in a case when a packet loss occurs during communication over TCP. Packet loss is a situation where a packet is not properly handled on a transmission line or on a packet relay apparatus (hereinafter referred to as a “relay apparatus”), and thus the packet is not delivered to a destination. FIG. 21 is an example in which an ACK to TCP segment X13 is not returned to server 203. A packet loss might have occurred on a transmission line in this case. Then, server 203 retransmits to client 204, TCP segment X14, which contains TCP data identical to the data contained TCP segment X13. Time X17, which is a time from transmission of TCP segment X13 to transmission of TCP segment X14 from server 203, is called an RTO (Round Trip Timeout). Time X16, which is a time from transmission of TCP segment X11 containing TCP data to return of ACK X12 in response to TCP segment X11, is called an RTT (Round Trip Time).
In the above-described examples of FIGS. 20 and 21, however, server 201 or 203 does not transmit subsequent data unless confirming receipt of an ACK from client 202 or 204 in response to a TCP segment that server 201 or 203 has transmitted. More specifically, unless server 201 or 203 receives from client 202 or 204, ACKs X2, X4, X6, X12, and X15 consecutively in response to transmitted TCP segments X1, X3, X5, X11, and X13=X14 respectively, server 201 or 203 does not transmit the subsequent data, thus deteriorating transfer efficiency. Therefore, the transfer method as described above is rarely applied. The transfer efficiency has been improved with various enhancements.
FIGS. 22 and 23 are conventional examples for improving the transfer efficiency with enhanced TCP flow control on a client side. In FIG. 22, server 205 consecutively transmits TCP segments X21 to X25 at a high speed. However, client 206 is sometimes unable to process TCP segments X21 to X25 transmitted from server 205. For example, TCP segment X25 is discarded and wasted due to delay in processing, although the TCP segment was once received on client 206.
To prevent the situation above, window size 112 in the TCP header of FIG. 19 is used to notify server 207 of a remaining amount of bytes for reception as shown with TCP segments X31 and X36 in FIG. 23. Such ACKs prevent the TCP segments transmitted from server 207, from being discarded when client 208 is unable to process the data. Server 207 is able to recognize the number of TCP segments that can be transmitted consecutively to client 208, based on window size field 112 in TCP header 103 of FIG. 19, for example. In FIG. 23, based on TCP segment X31 from client 208 that notifies server 207 of a window size of 4000 bytes, server 207 transmits to client 208, TCP segments X32 to X35, which contain 1000 bytes each and thus make a total of 4000 bytes. Similarly, based on TCP segment X36 from client 208 that notifies server 207 of a window size of 4000 bytes, server 207 transmits to client 208, TCP segments X37 to X40, which contain 1000 bytes each and thus make a total of 4000 bytes.
FIG. 24 illustrates a TCP behavior in a case when a packet loss occurs during flow control with the window size. When server 209 transmits a TCP segment (byte 1000 to byte 2000) and client 210 completes receiving the TCP segment, client 210 transmits to server 209, ACK X54, which carries a number that indicates receipt of the TCP segment (ACK 2001). When a packet loss occurs in transmission of TCP segment X55 (byte 2001 to byte 3000) from server 209, TCP behaves as described below. Even when client 210 receives, from server 209, TCP segment X56 (byte 3001 to byte 4000) or TCP segment X58 (byte 4001 to byte 5000) after transmitting ACK X54 to server 209, client 210 further returns, to server 209, ACKs X57 and X59 identical to X54 (hereinafter such ACKs referred to as “duplicate ACKs”), since client 210 has yet to receive TCP segment X55 (byte 2001 to byte 3000). Server 209 then receives ACKs X54, X57, and X59, which include the number that indicates receipt through X53 on client 210 (ACK 2001), for a plurality of times. Thereby, server 209 recognizes that client 210 cannot receive TCP segment X55 due to packet loss at least in TCP segment X55, although server 209 has transmitted, to server 210, TCP segment X56 (byte 3001 to byte 4000) and TCP segment X58 (byte 4001 to byte 5000). At this point, server 209 retransmits TCP segment X55 as X60.
FIG. 25 is a conventional example that shows efficient transmission of an ACK. Instead of transmitting the ACK associated with the individual TCP segment as shown in FIG. 24, client 212 transmits to server 211, one ACK X74 or X78, which includes a confirmation reply to a plurality of TCP segments X71 to X73 or X75 to X77, thus allowing efficient transmission of the ACK. Such ACK shall be transmitted normally within 0.5 second.
FIGS. 26 and 27 are other conventional examples of efficient transmission and reception of TCP data. The examples illustrate a method where a TCP data transmitter transmits a TCP segment to a TCP data receiver, based on a window size (i.e., a maximum amount of data that the TCP data receiver can buffer before processing a received TCP segment) received from the TCP data receiver. The method employs a concept called a congestion window (hereinafter referred to as CWND). The method is effective when a transmission line between a server and a client has a sufficiently large transmission capacity.
Practically, however, the server and the client are connected via a plurality of transmission lines having a variety of transmission capacities. Further, with improvement in calculation performance these days, the client tends not to advertise a small window size. When the data transmitter consecutively transmits all TCP data up to the window size that the data receiver advertises, there is a possibility where transmission throughput may exceed a small transmission capacity of some transmission line during transmission on the plurality of transmission lines. Under the circumstance, a number of packet losses occur in the method, and thus the throughput declines.
To address the problem, a mechanism of CWND is applied to perform flow control on the TCP data transmitter as well. CWND is employed on the data transmitter. Even when the data transmitter receives a large window size from the client at the start of data transmission, the data transmitter transmits only one TCP segment at the beginning. That is, the transmission starts at CWND=1. Thereafter, CWND is increased to find an optimum CWND value.
As shown in FIG. 26, every time server 213 receives from client 214 an ACK in response to a transmitted TCP segment containing TCP data, server 213 exponentially increases the number of TCP segments, that is, the CWND value, for next transmission. More specifically, in FIG. 26, server 213 first starts the transmission at CWND=1. When receiving from client 214 ACK X82 in response to transmitted TCP segment X81, server 213 sets CWND=2 and consecutively transmits TCP segments X83 and X84. When receiving from client 214 ACK X85 in response to TCP segments X83 and X84, server 213 sets CWND=4 and consecutively transmits TCP segments X86 to X89. When further receiving from client 214 ACK X90 in response to TCP segments X86 to X89, server 213 sets CWND=8 and consecutively transmits eight TCP segments from TCP segment X91.
Server 213 continues to increase the CWND value not exceeding the window size advertised by the client, until a state of congestion (when a TCP segment is retransmitted due to packet loss or RTO expiration) is detected.
When the state of congestion occurs, server 213 decreases the CWND value by half of the point of occurrence, for example, and then linearly increases CWND not exceeding the window size advertised by the client as shown in FIG. 27.
A data transmission method after the state of congestion as shown in FIG. 27 is called “congestion avoidance mode.” On the other hand, a state before the state of congestion as shown in FIG. 26 is called “slow start mode.” An increase in CWND is large in slow start mode and small in congestion avoidance mode. Once switching to congestion avoidance mode, server 213 remains in the mode, not switching back to slow start mode, until one session ends.
Communication between the server and client is performed at the optimum CWND value obtained as above. In most of the recent TCP application, the above-described congestion window is used in transmission and reception.
A timing to switch from slow start mode to congestion avoidance mode may be set to a point when CWND exceeds a certain threshold in slow start mode (hereinafter referred to as a “slow start threshold”), instead of occurrence of congestion or RTO expiration as described above. The slow start threshold may be appropriately determined by an installer.
From the description above, four parameters listed below are related to the TCP throughput.
A) RTT: The throughput decreases as the RTT increases; the throughput increases as the RTT decreases.
B) CWND: The throughput increases as CWND increases; the throughput decreases as CWND decreases.
C) Window size: Increasing the window size may increase the throughput (depending on CWND). Decreasing the window size decreases the throughput, regardless of the CWND size.
D) TCP transmission mode: In slow start mode, the throughput sharply increases; in congestion control mode, the throughput moderately increases. The transmission mode is switched when congestion occurs in slow start mode or when CWND exceeds the slow start threshold in slow start mode.
As the Internet has been widely used these days, an Internet telephone (hereinafter referred to as an “IP telephone”) system has been gaining popularity. In the IP telephone system, voice communication between Internet terminals is performed using a packet containing audio data. The IP telephone system includes two or more IP telephone terminals, which perform voice communication normally over UDP.
At the same time, a method for accessing the Internet on an ADSL (Asymmetric Digital Subscriber Line) or a CATV network has been widely used at home. When connecting to the Internet over the ADSL or CATV network at home, a relay apparatus is mostly used to relay a packet from an Internet terminal at home to an ISP (Internet Service Provider) or to relay a packet from the ISP to the Internet terminal at home (hereinafter the relay apparatus having the above-described functions is referred to as an “access router”). Although a transmission capacity of an access line to a home over ADSL or CATV has been increasing year after year, use of an access line that provides a bidirectional transmission capacity of 10 Mbps, such as the Ethernet, is still limited.
Recently, a trial as shown in FIG. 2 has been vigorously pursued, wherein access router D2 that functions as a gateway to the above-described home network is provided with an IP telephone function. In FIG. 2, TCP segment D5 and voice communication packet D4 are mixed on upper level transmission line D3. TCP segment D5 is transmitted between client D1 and server D7. Voice communication packet D4 over UDP is transmitted between IP telephone D8 and access router D2 installed with the IP telephone function. Further, a transmission capacity of upper level transmission line D3 is 1 Mbps, which is smaller than that of other transmission lines D9 and D10. Particularly when TCP segment D5 and voice communication packet D4 are transmitted simultaneously, a transmission amount may exceed the transmission capacity of transmission line D3. When the transmission amount exceeds the transmission capacity, a packet transmission queue or a packet reception queue of access router D2 is extended to a maximum length, thus causing a packet loss.
The packet loss has a significant impact on audio quality of voice communication packet D4 in particular. In addition, as the transmission amount on upper level transmission line D3 approaches the transmission capacity due to the TCP segment, jitter of the voice communication packet (refer to Publication 1, for example) generally becomes large, which also has a significant impact on the audio quality. The phenomenon is observed not only on access router D2, but also on upper level relay apparatus D6. Therefore, in order to improve the audio quality in the configuration as shown in FIG. 2, the throughput of the communication packet other than the voice packet, that is, the throughput of TCP segment D5 in FIG. 2, needs to be purposely lowered. Access router D2 can control an output packet so as to lower the upstream throughput of TCP segment D5 in FIG. 2, excluding the voice packet. It is difficult for access router D2, however, to control the downstream throughput, since upper level relay apparatus D6 transmits the TCP segment and the voice communication packet.
Communication other than the voice communication at home is mainly performed in a reliable transmission method, such as TCP. In order to purposely lower the downstream throughput of the TCP communication other than the voice communication and to ensure the audio quality by relatively prioritizing the voice communication, a known method is to “lower a window size value from a client” (refer to Related Art 1, for example).    [Related Art 1] Specification of U.S. Pat. No. 6,038,216    [Publication 1] Schulzrinne, H. “RTP: A Transport Protocol for Real-Time Applications.”    RFC number: 1889 [online]. January, 1996. The Internet Engineering Task Force.    [retrieved on Apr. 10, 2006]. Retrieved from the Internet:    http://www.ietf.org/rfc/rfc1889.txt
However, a client terminal may be set to ignore the window size. Thus, the technology of Related Art 1 is not effective for the client incapable of processing the window size. With the technology, the downstream throughput of the TCP communication except of the voice communication cannot be lowered purposely, and thus the audio quality cannot be ensured.